home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19950528-19950726 / 000298_news@columbia.edu_Mon Jul 10 20:21:46 1995.msg < prev    next >
Internet Message Format  |  1995-07-31  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA27902
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 10 Jul 1995 20:01:42 -0400
  3. Received: by apakabar.cc.columbia.edu id AA05361
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 10 Jul 1995 20:01:40 -0400
  5. Path: news.columbia.edu!panix!news.mathworks.com!gatech!howland.reston.ans.net!agate!news.mindlink.net!vanbc.wimsey.com!ddsw1!news.mcs.net!not-for-mail
  6. From: les@MCS.COM (Leslie Mikesell)
  7. Newsgroups: comp.protocols.kermit.misc,comp.dcom.modems
  8. Subject: Re: Portable Dialing Directory Design
  9. Date: 10 Jul 1995 15:21:46 -0500
  10. Organization: /usr/lib/news/organi[sz]ation
  11. Lines: 84
  12. Message-Id: <3ts24q$t76@Mercury.mcs.com>
  13. References: <3tp5ma$drl@apakabar.cc.columbia.edu>
  14. Nntp-Posting-Host: mercury.mcs.com
  15. Xref: news.columbia.edu comp.protocols.kermit.misc:3133 comp.dcom.modems:101675
  16. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  17.  
  18. In article <3tp5ma$drl@apakabar.cc.columbia.edu>,
  19. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  20.  
  21. >For a dialing directory to be "portable", it should work no matter where
  22. >you are calling from:
  23.  
  24. The free unix Hylafax software (sgi.com:/sgi/fax/) handles this with
  25. a "dialrules" file that consists of lists of regexp substitutions
  26. that are applied in order along with some simple variable expansions.
  27. Three separate sets are used to determine the actual number dialed
  28. by the modem, the "visible" representation as might be used on
  29. a cover page, and a canonical form used for logfile names.  This
  30. is a bit cumbersome to set up, but it's the only thing I've seen
  31. that actually works.
  32.  
  33. >3. The DIAL PREFIX.  This is used for specifying a code to be dialed in
  34. >   order to get an outside line, e.g. when dialing from a PBX or hotel room.
  35. >   In other words, this is a prefix to be ADDED to the beginning of the
  36. >   phone number that is extracted from the dialing directory.
  37.  
  38. What if you are behind a PBX and send to another extension?   The
  39. hylafax system can be tuned to recognize local extensions and 
  40. dial them without adding the prefix, and still use the same
  41. logfile as it would if you dialed the number through an outside
  42. line. 
  43.  
  44. >If a person always dials from the same place, then each number can be
  45. >entered in the dialing directory in exactly the way the person dials it:
  46. >local, long-distance, tie-line, internal PBX number, etc.  That is what we
  47. >had before, and it works for most people.
  48.  
  49. If you define a standard PREFIX and AREA CODE to be assumed within
  50. the dialing directory, then you can recognize them and allow them
  51. to be used or omitted so people can use the number they would commonly
  52. dial from their office phone or not.  
  53.  
  54. >But to meet the needs of those who travel around with their dialing
  55. >directories, or for that matter to construct dialing directories which
  56. >themselves are portable, e.g. to be shipped to people in diverse locations
  57. >throughout the world, what is the least amount of complexity and
  58. >"knowledge" we can get away with?
  59.  
  60. Then instead of changing the PREFIX and AREA CODE you have different
  61. on-the-road versions. You can undo the assumptions made at the office
  62. to construct a canonical form, then re-do the dialing procedure
  63. needed for the current location.  Hylafax doesn't have a handy way
  64. to add variables without editing the dialrules file, but the processing
  65. could be done with the mechanism provided.
  66.  
  67. >Now all of this is quite complex already.  Is there a chance in the world
  68. >that anybody will remember these points or use these features?  Is there any
  69. >way to make them simpler?  If so, it is not obvious to me.
  70.  
  71. It gets worse.  We can prefix calls out of the PBX with #7nnn (where
  72. nnn is another extension) to internally bill the call to a different
  73. number which is extremely handy for shared modems on a computer.  The
  74. regexp based substitutions let me recognize this as a special case
  75. and move it out of the way while performing the other steps. 
  76. I'm not sure if anyone else is perverse enough to actually use
  77. rules like this, though.
  78.  
  79. >One idea that suggests itself is to separate the notions of:
  80. >
  81. > 1. Prefix for long distance calls within the country I am in.
  82. > 2. Prefix for calling outside the country I am in.
  83. > 3. The area code of the area I am in.
  84. > 4. Country code of the country I am in.
  85. > 5. Country code for dialing in to each country from outside.
  86. > 6. Area codes within any given country.
  87.  
  88. If you have to build any concepts in, it should cover how to
  89. build a canonical form out of any likely local representation,
  90. then how to dial the canonical form from any likely locality.
  91. That will ensure that you can use a canonical form (+country...)
  92. in the directories without any new problems.  That means you
  93. need to recognize numbers with/without any combination of
  94. pbx-prefix, ld-prefix, country-code, and area code, removing
  95. the local versions, then putting back what you need for the
  96. canonical number.  And this still leaves the problem of
  97. calling another extension on your PBX.
  98.  
  99.  
  100. Les Mikesell
  101.   les@mcs.com